The present invention relates generally to data processing, and more particularly, to software development, including techniques for facilitating debugging of code of a computer program.
A programmer conventionally develops a software program using a text editor to create source code files. From these source code files, an executable program is generated by translating the source code files into an executable program or machine code. The process of generating the executable program from the source code may involve the use of several software programs. These programs typically include a compiler for translating the source code into machine code and a linker to link the machine code together to form the executable program.
Source code files of a computer program may include thousands, if not millions, of lines of source code, often spread across many files. Because of this complexity, software programs may contain errors that manifest themselves during program execution. Accordingly, a debugging tool has been an essential tool of software development. Debugging involves testing and evaluating the software program to find and correct errors, including any improper logic operations. Typically, a debugging program allows a developer to monitor the execution of a computer program. Doing so assists the programmer in finding and correcting errors. A typical debugging system includes a combination of computer hardware and debugger software that executes the program being debugged in a controlled manner. Controlled debugger execution is facilitated, in part, using two operations: step functions and user breakpoints.
A “step” function permits a computer programmer to process lines (also referred to as “statements”) in a computer program one-by-one, and to see the results upon completion of each line. To accomplish this, the debugger needs to maintain program control, which means that the program must be interrupted and the debugger notified when program execution reaches the next line or statement of a program that has been compiled to allow execution to be controlled by the debugger. Because of the rich features offered by many high level programming languages, it is often not tractable or possible for a debugger to predict which line will execute next. This is especially true when considering, for example, signals and try/catch/throw constructs, method calls, Run Time Library (RTL) routines such as setjmp( ) longjmp( ) and exit routines such as the one provided to the C RTL routine atexit( ).
On a zSeries® or System Z® computer system, offered by International Business Machines Corporation, of Armonk, N.Y., maintaining program control when stepping over these constructs can be involved. For these systems, software debuggers are conventionally dependent on programs being compiled in such a way that operating system “hooks” (referred to as EX hooks) are inserted in order for the debugger program to retain program control, for example, when performing a step operation. Unlike other operating systems, the zOS® system supports many linkage conventions, and does not provide support to notify the debugger program when a particular function is called. Plus many of the run-time routines exist in read only memory and are in fact shared by multiple users so there is no way for a debugger to set breakpoints to instruction step the user through these routines.
Thus, operating system hooks are inserted at compile time, and there may be more than one hook inserted per instruction. Many debuggers rely on such operating system hooks to retain control during a step operation. However, with the use of operating system hooks, the average program becomes larger when compiled for debugging. In addition, executing such a compiled program may result in the program running slower than the same program compiled without hooks. The reason for this is that, upon encountering a hook, even outside the debug environment, additional time is needed to execute the hook compared with regular program instructions. Due to this performance issue, there is an advantage to being able to limit the insertion of operating system hooks.